…ride (#146)

`runReview` read the built-in glossary file directly and never looked at
`inputs.glossaryPath`, so a repo with a custom glossary had its
translation produced against one terminology and judged against another.
The failure was silent — the run logged `✓ Loaded glossary for <lang>`
either way — and it mattered more after v0.22.0 made `terminology` a
gating category: a reviewer judging against the wrong glossary
suppresses the auto-merge gate on correct work and biases the Stage 4
shadow calibration the per-criterion floors will be chosen from.

Review now goes through the same `loadGlossary` that sync and rebase use.

Fixing that surfaced a deeper defect in the shared loader, which the
issue did not describe: the custom path was tried AFTER the built-in
one, so for every language that ships a glossary — zh-cn, fa, fr, the
whole estate — `glossary-path` was silently ignored in all three modes,
not just review. An unreadable custom file also quietly degraded to
built-in terminology.

- a custom glossary is now an override: the only candidate when set
- a path that cannot be read or parsed fails the run rather than
  falling back to terminology the operator did not ask for
- the mode logs which glossary it used, custom or built-in

No production edition sets `glossary-path`, so nothing in the fleet
changes behaviour today.

Also fixed while in there: a repository whose name carries no language
suffix reviewed with no glossary and said nothing — it now warns. The
reviewer's glossary-to-prompt formatting moved out of src/index.ts,
which `import.meta.url` puts beyond the Jest CJS registry and so beyond
testing, into `formatGlossaryTerms` with tests.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… too

Addresses Copilot's review of #151.

1. The thrown message for an unreadable custom glossary interpolated the
   caught Error object, so run()'s `Action failed: ${error.message}`
   wrapper produced a doubled prefix:
     Action failed: Could not load custom glossary from X: Error: ENOENT…
   (Copilot predicted "[object Object]"; that needs a thrown plain
   object, which fs.readFile and JSON.parse never produce. The doubled
   prefix is the real symptom.)

2. The built-in branch checked only `if (glossary)` while the custom
   branch validated `Array.isArray(glossary.terms)` — an asymmetry
   introduced when the custom branch was hardened. A glossary whose
   `terms` was present but not an array logged "with undefined terms"
   and was RETURNED, then failed downstream in formatGlossaryTerms or
   the translator, far from the cause. Both branches now go through
   readGlossaryFile, keeping the validation identical while leaving the
   consequence deliberately different: a bad custom path is operator
   misconfiguration and fails the run, a corrupt built-in glossary is a
   broken install and warns.

The error helper is duck-typed rather than using this codebase's
`error instanceof Error` idiom, and that is load-bearing: fs.promises
rejections cross a realm boundary under Jest's vm context, so
`instanceof Error` is FALSE for them despite constructor.name being
Error — the idiom falls through to String(error) and re-adds the very
prefix it exists to strip. Cosmetic-only in production (single realm),
but it is the difference between this being testable and not. The
regression test caught exactly that while the first version of this fix
was in place.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>